Date: Thu, 7 Apr 94 04:30:09 PDT 

From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu> 
Errors-To: Ham-Digital-Errors@UCSD.Edu 

Reply-To: Ham-Digital@UCSD.Edu 

Precedence: Bulk 

Subject: Ham-Digital Digest V94 #101 

To: Ham-Digital 


Ham-Digital Digest Thu, 7 Apr 94 Volume 94 : Issue 101 


Today's Topics: 
Baycom TCP/IP Software 
FCC Packet Message Forwarding 
MFJ 1270C TNC and Host Mode 
spread-spectrum links hooking libraries in CA.. 
Televideo 925 terminal setup 
X1-J and DRSI DPK-2 TNC's 


Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu> 
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: 6 Apr 94 20:19:27 GMT 
From: news-mail-gateway@ucsd.edu 
Subject: Baycom TCP/IP Software 
To: ham-digital@ucsd.edu 


>Is there a driver available for TCP/IP on the Baycom software and modem? 
There is a file AX25DRV.ZIP available which contains a driver and 
instructions. It should be on ucsd.edu somewhere in 
/hamradio/packet/tcpip and is also available on the TAPR 

fileserver. Send a message to file-request@tapr.org with the 

lines: 


get /pub/packet/ax25drv.zip 


and it will be send uuencoded. 


Date: 7 Apr 1994 05:11:17 GMT 

From: ihnp4.ucsd.edu!swrinde! gatech!udel!news.sprintlink.net!connected.com! 
krel.iea.com!comtch! chuckv@network.ucsd.edu 

Subject: FCC Packet Message Forwarding 

To: ham-digital@ucsd.edu 


Well it's final.... Here is the latest rule from the FCC..... 


Report No. DC-2582 ACTION IN DOCKET CASE April 4, 1994 


COMMISSION AMENDS RULES CONCERNING MESSAGE FORWARDING 
SYSTEMS IN THE AMATEUR SERVICE 
(PR DOCKET NO. 93-85) 


The FCC has relaxed the amateur service rules to enable 
contemporary message forwarding systems to operate at hundreds of 
characters per second while retaining safeguards to prevent misuse. 


A message forwarding system is a group of amateur stations 
participating in a voluntary, cooperative, interactive arrangement 
where communications from the control operator of an originating 
station are transmitted to one or more destination stations via 
forwarding stations, which may or may not be automatically 
controlled. 


Currently, the control operator of each station is held 
individually accountable for each message retransmitted, resulting 
in unnecessary content review and delays. The American Relay 
League, Inc. (League) stated that the obligation of the control 
operator of the first forwarding station should be the 
establishment of the identity of the station originating the 
message. Only when this is not done should these control operators 
be held accountable for improper message content. Also, there are 
currently no central supervisory authority in an ad hoc amateur 
service digital network, making these unsupervised systems easy 
targets for misuse by uncooperative operators and non-licensees. 
Moreover, the Commission said that it could be difficult to 
establish after the fact that a particular VHF station originated 


a fleeting high speed digital transmission. For these reasons, the 
Commission said there must be on-going oversight of the system and 
the control operators of the first forwarding stations are in the 
best position to provide such oversight. 


Therefore, the Commission will hold accountable only the 
licensees of the station originating a message and the license of 
the first station forwarding a message in a high speed message 
forwarding system. The licensee of the first forwarding station 
must either authenticate the identify of the station from which it 
accepts communications on behalf of the system, or accept 
accountability for the content of the message. 


(over) 


20.2 


The Commission also clarified that the station that receives 
a communication directly from the originating station and 
introduces it into the message forwarding system is the first 
forwarding station. 


The League and the Colorado Council of Amateur Radio Clubs 
suggested that the Commission substitute the word "simultaneously" 
for "instantaneously" in the redefinition of a repeater. The 
Commission concurred and adopted this modification. 


The Commission believes that these rule changes will enable 
contemporary high speed message forwarding systems to operate as 
their designers intended, while retaining the minimum safeguards 
necessary to prevent misuse. 


Action by the Commission March 30, 1994, by Report and Order 
(FCC 94-76). Chairman Hundt, Commissioners Quello and Barrett. 


-FCC- 


News Media contact: Patricia A. Chew at (202) 632-5050. 
Private Radio Bureau contact: William T. Cross at (202) 632- 
4964. 
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Date: 6 Apr 94 20:26:42 GMT 

From: news-mail-gateway@ucsd.edu 
Subject: MFJ 1270C TNC and Host Mode 
To: ham-digital@ucsd.edu 


>I've been looking through my TNC documentation, and the only reference I find 
>to host mode mentions that documentation is available on diskette, but no 
>command is given for putting the TNC into host mode. 

> 

>Can anyone help? 


There is a disk containing discriptions of the host mode and a 
primative program to use it available from TAPR. Also a file with 
documentation up to TAPR version 1.1.8a firmware, which has the 
pertinent commands (with much other valuable TNC information). Senda 
message to file-request@tapr.org with the following lines in the 

body of the message: 


get /pub/packet/tnc2host.zip 
get /pub/packet/tnc2doc.zip 
quit 


The files will be sent to you uuencoded. 


Bob Nielsen, W6SWE Internet: w6swe@tapr.org 
Tucson, AZ AMPRnet: w6swe@w6swe.ampr.org 
[44.124.12.16] AX.25: w6swe@wb7tls.az.usa.na 


Date: Wed, 6 Apr 1994 15:08:26 GMT 

From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!news.ans.net!paperboy.amoco.com! 
apctrc!msc.edu!mr.net!idss.nwa.com!csinc!chrise@network.ucsd.edu 

Subject: spread-spectrum links hooking libraries in CA.. 

To: ham-digital@ucsd.edu 


I remember reading about a project some of the guys on here did a while 
back to hook libraries in some part of California to the Internet using 
part 15 spread-spectrum equipment. Are those guys still around ? If so, 

I have a couple questions for you and would like to discuss that project... 
Could you email me ? 


Thanks. 


Chris 


Chris Elmquist, NOJCF voice: (612)631-7614 
chrise@comtrol.com fax: (612)631-8117 


Date: Thu, 7 Apr 1994 02:48:33 GMT 

From: ihnp4.ucsd.edu!swrinde!cs.utexas.edu!howland.reston.ans.net! 
europa.eng.gtefsd.com!news.umbc.edu!eff!news.kei.com!ub!acsu.buffalo.edu! 
jwelch@network.ucsd.edu 

Subject: Televideo 925 terminal setup 

To: ham-digital@ucsd.edu 


Anyone have the manual for a Televideo 925 terminal? I have purchased one 
second hand, and would appreciate any information about the two banks of DIP 
switches at the back of the terminal. One is labelled baud (but no explanation 
of what switches select which speed). The other is labelled function. I 
believe that there is also a third bank of switches inside the unit. Any help 
would be appreciated. 


Thanks, 


John Welch 
KA2VGV 


Date: 7 Apr 94 06:09:08 GMT 

From: VNET.IBM.COM@uunet.uu.net 
Subject: X1-J and DRSI DPK-2 TNC's 
To: ham-digital@ucsd.edu 


I'm planning to install a X1-J rom in to a DRSI DPK-2. Is there anything 
I should look out for before doing the bank switching mod??? 


Oh and also is there a sourceon info on wiring a TNc w/ a 9600 bd modem 
to a Motorola Maxtor UHF radio. 


Thanks 
Stephen sharp 


IBM, Micro Electronics Div. 
Burlington, VT Internet ID: ssharp@vnet.ibm.com 


Date: 6 Apr 1994 22:10:39 GMT 
From: news.mentorg.com!hpbab33.mentorg.com!wv.mentorg.com! hanko@uunet.uu.net 
To: ham-digital@ucsd.edu 


References <1994Mar29.100554.3059@hemlock.cray.com>, 
<2nphhd$djt@hpbab.mentorg.com>, <2nqghsn$£9s@network.ucsd.edu>om 
Reply-To : Hank_Oredson@mentorg.com 

Subject : Re: [REPOST] The # in PBBS addresses.... 


In article <2nghsn$f£9s@network.ucsd.edu>, brian@nothing.ucsd.edu (Brian Kantor) 
writes: 

|> In article <2nphhd$djt@hpbab.mentorg.com> Hank_Oredson@mentorg.com writes: 
|> >You are perhaps talking about the internet, which chose to ignore 

|> >the existing use of NA in one of it's connected networks? 

|> 

|> Oh jeez, Hank, stop making things up. The AMPR.ORG domain has never used 

|> the ham bbs hierarchical routing/addressing scheme to name hosts. 


We were not discussing host names. We were discussing email addresses. 


Please do not confuse a host name with an email address, this is one of the 
worst mistakes an email system designer might make. 


But since you brought up the topic, why would AMPR.ORG xnotx choose some 
sort of rational subdomain naming convention for host names? 


Perhaps the fact that they didn't, and that they consistently confuse email 
addresses with host names is why it is impossible to move email from 

one tcp/ip system within .ampr.org to another without making use of those 
"other" (BBS network) email addresses? 


But now back to our scheduled discussion of email addresses. 


|> With some exceptions, the namespace of the AMPR.ORG domain consists 

|> solely of callsigns within the domain. Names are not routes, routes 

|> are not names, and mixing them up is one of the worst possible mistakes 
|> a network architect could make. 


Well gee Brian! Glad you least understand the basics! 
A name is not a route. 

A route is not a location. 

An address is none of the above. 

Etc. etc. 

So *WHY* do you persist in confusing them? 

Repeat after me "A host name is not an email address." 


|> That means that whilst you might see 
|> WORLI.AMPR.ORG 

|> ox 

|> BBS.WORLI.AMPR.ORG 

|> you won't see 

|> WORLI.#NNJ.NJ.USA.NOAM.AMPR.ORG 

|> or the like 


And why would I not see such things? 

Why would we not use subdomains in our email addresses? 

Why would we not put routing hints into our email addresses? 

Why would we not identify our email address by it's internet domain name. 


Why wait! Look at my signature! 

It has ".mentorg.com", which clearly is an internet domain name! 

But wait ... there is something missing - the subdomains. 

Why are they missing? Because a router with address "mentorg.com" 
will take care of translating the (missing) portion of my email 
address once email addressed to the "mentorg.com" domain arrives 
there. Where is "there"? Well, that depends on where your email 

to me started ... "there" might be NJ or OR or Bracknell or Singapore. 
At any one of these locations email destined for <x>.mentorg.com 

is re-routed by adding the rest of the address. 


So the rest of the world does not need to know about .hanko.mentorg.com, 
nor about .hanko.moses.mentorg.com, nor about 
hanko.moses40.moses.mentorg.com 


We use ABBREVIATIONS and ALIASES for the actual addresses. 
What does this have to do with the ham radio digital network? 


In the ham radio digital network, we do not yet use aliases nor 
abbreviations. We specify the whole email address. 


(Note for Brian: this is NOT "source routing" since we do not specify a 
route, but specify an address). 


Look again in my signature. I show a ham radio digital network email 

address. There is *xnox "host name" in that address. There are in fact two 
hosts that may handle email addressed to my address: RLIMB:WORLI-2 and 
WLINN2:WORLI-4. These are the host addresses within the AX.25 network. 

In the CLOVER network, that first host is named WORLI. This is not 

confusing to anyone, because the WORLI name is only known in the CLOVER 
network, and the RLIMB and WLINN2 names are only known in their respective 
AX.25 networks. If I had a tcp/ip system on air, it would have an ip address. 


Most folks have no trouble distinguishing between the email address and the 
host name. It is not a complicated thing. In fact it is very simple: 
email destined for email addresses of the form ".OR.USA.NOAM" may be sent 
to any of the hosts listed in the previous paragraph, and it will be 
properly delivered. Oh yes - email addresses of the form ".WA.USA.NOAM" 
may also be sent to these hosts as well. If you want email to reach me 
personally you may send it addressed per my signature, and to any of those 
same hosts. 


Brian, now that you have again told us "Don't do it that way" would you please 
oh please tell us "The right way to do it." 


Hank 


Hank Oredson @ Mentor Graphics 
Internet : hank_oredson@mentorg.com 
Amateur Radio: WORLI@WORLI.OR.USA.NOAM 


Date: 6 Apr 94 23:17:20 GMT 

From: dog.ee.lbl.gov!ihnp4.ucsd.edu!news.cerf.net!ccnet.com!ccnet.com!not-for- 
mail@ucbvax.berkeley.edu 

To: ham-digital@ucsd.edu 


References <2nph5e$djt@hpbab.mentorg.com>, <Cnr9x1.II16@world.std.com>, 
<2nuqbe$omj@hpbab.mentorg.com> 
Subject : Re: NTS traffic on packet 


Hank Oredson (hanko@wv.mentorg.com) wrote: 


: What would prevent duplicates or lost messages? 
: How would you accomplish this? Remember we don't have a "fixed 
configuration" network. We don't have reliable paths. We do have multiple 


I don't understand. There are fixed routes in and out of any full service 
bbs. The HF routes may seasonally change and require manual assistence. 
What is going to happen if the BBS protocol is allowed to be the rule on 
the DASH digital amateur super highway. It is my understanding that the 
proposal for the 219 MHz 56kb DASH will require point to point auxiliary 
operation. Will the bbs protocol work in this new arena? 


: ways to get from point A to point B. We don't have a protocol that 
: addresses all the problems, and would xlovex to have one. 


: Any suggestions would be most welcome. 
: I hope we will hear from the networking gurus on these topics. 


: So far, we have heard from a couple of the networking gurus. 
: Their message has been "You are doing it wrong." 
: I presume they will follow up with "And here is how to do it right." 


("just use tcp/ip" is not a reasonable answer. We don't use it.) 


Maybe the answer is to make the 219 MHz DASH a tcp/ip network and put the 
bbs mail traffic into <envelopes> for safe transport across the network. I 
would like to see some more discussion on the future implementation of 
this new network. 


Has anyone done any traffic analysis of bbs messages? Are the bulk of the 
messages two or three hops? With the increase in network speed will the 
message flow naturally increase? Will my bbs mail reading program be able 
to keep up with the vast number of bulletins that will be arriving? I 
realize that I will be reading at 1200 for quite some time ... maybe 9600 
if the bbs operators will provide this service. 


Sorry Hank, I am not a network guru, just your average packet user. 


Bob 


: Hank Oredson @ Mentor Graphics 
: Internet : hank_oredson@mentorg.com 
: Amateur Radio: WORLI@WORLI.OR.USA.NOAM 


Bob Wilkins work bwilkins@cave.org 
Berkeley, California home rwilkins@ccnet.com 
94701-0710 play n6éfri@né6eeg.#nocal.ca.usa.noam 


Date: 6 Apr 1994 17:09:02 GMT 


From: news.mentorg.com!hpbab33.mentorg.com!wv.mentorg.com! hanko@uunet.uu.net 


To: ham-digital@ucsd.edu 


References <CnJL6K.Loq@world.std.com>, <2nph5e$djt@hpbab.mentorg.com>, 
<Cnzr9x1.IIl6@world.std.com>g.c 


Reply-To : Hank_Oredson@mentorg.com 
Subject : Re: NTS traffic on packet 


In article <Cnr9x1.I16@world.std.com>, dts@world.std.com (Daniel T Senie) writes: 
|> In article <2nph5e$djt@hpbab.mentorg.com> Hank_Oredson@mentorg.com writes: 

|> >In article <CnJL6K.Loq@world.std.com>, dts@world.std.com (Daniel T Senie) 
writes: 

|> >|> In article <2nejic$j75@hp-col.col.hp.com> jms@col.hp.com (Mike Stansberry) 
writes: 

|> >|> >Jeffrey D. Angus (jangus@skyld.grendel.com) wrote: 

|> > 

|> >|> I have lately seen traffic duplicated 2 or 3 times. One message I sent to 
|> >|> my STM at the other end of the section got there 4 times. We have had 

|> >|> a rash of multiple NTS deliveries. 

|> > 

|> >This is a very serious problem. 

|> > 

|> >There are many possible causes, but they all come down to poor operating 

|> >practices by the sysops. If the sysops had things set up reasonably, 

|> >and made certain their systems were operating properly, then there would 

|> >be no (zero, zilch, none) duplicated bulletins. 

|> > 

|> >Personal messages and NTS traffic are handled differently. 

|> >Duplicates are allowed to occur, rather than lose an occasional message. 

|> >However, these duplicates should be rare: 1 in 1000 perhaps. 

|> 

|> This raises some alarm bells with me. Networks need to either send or not 

|> send messages. Protocols are designed to be able to be sure of such things. 
|> Could you imagine if something like an international money transfer were 

|> occasionally duplicated on the commercial networks? It sounds like the 

|> protocols involved (in nthis case, the handling methods) may need some 

|> review. 


We are not talking "banking networks" here, we are talking about a network 
rather similar to the internet. Duplicates occur. Such is life. 
Any suggestions you have would be most welcome ... 


|> Why is the software designed to allow even an occasional duplicate? Why 
|> is there otherwise the possibility of a lost message? 


What would prevent duplicates or lost messages? 

How would you accomplish this? Remember we don't have a "fixed 
configuration" network. We don't have reliable paths. We do have multiple 
ways to get from point A to point B. We don't have a protocol that 
addresses all the problems, and would xlovex to have one. 


Any suggestions would be most welcome. 


I hope we will hear from the networking gurus on these topics. 


So far, we have heard from a couple of the networking gurus. 
Their message has been "You are doing it wrong." 
I presume they will follow up with "And here is how to do it right." 


("just use tcp/ip" is not a reasonable answer. We don't use it.) 


Hank 


Hank Oredson @ Mentor Graphics 
Internet : hank_oredson@mentorg.com 
Amateur Radio: WORLI@WORLI.OR.USA.NOAM 


End of Ham-Digital Digest V94 #101 
KAKKKKKKKKKKKKKKKKKKKKKKEKR KAKA 
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